Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.353 < prev next >

Wrap

Text File | 1996-02-12 | 28.0 KB | 533 lines

Frequently Asked Questions (FAQS);faqs.353 ---------------------------------------------------------------- ;;; ******************************** ;;; Change Log ********************* ;;; ******************************** ;;; Date Who Ver Reason ;;; ------------------------------------------------------------ ;;; 7-FEB-92 mk 1.0 Initial release. ;;; 10-FEB-92 mk 1.1 Pre-release corrections and additions. ;;; 10-FEB-92 mk 1.11 Minor changes from Arun Welch, Mitch Marks, ;;; Mike Meyer, Matthias Felleisen, and John Gateley. ;;; 11-FEB-92 mk 1.12 Corrections by John Carroll, Jason Trenouth, Joel ;;; Riedesel, David Neves, Lawrence Mayka and ;;; Bruce Miller. ;;; 13-FEB-92 mk 1.13 Renumbering. Split into 3 files. Some more FAQs. ;;; 23-MAR-92 mk 1.14 Updated various FTP entries, bug in EXPLODE. ;;; Updated harlequin entry. ;;; 25-MAR-92 mk 1.15 Added question [2-18]: saving data and CLOS ;;; instances to disk for later retrieval. ;;; 1-MAY-92 mk 1.17 Added entry for Feel to question [1-5]. Updated CMU ;;; ftp machines to point to ftp.cs.cmu.edu. Fixed CMU ;;; CL entry to be approximately version independent. ;;; Revised entry on Garnet. uunet.uu.net -> ftp.uu.net ;;; 12-MAY-92 mk 1.18 Split questions 1-5, 1-6, and 1-7 into part 4, ;;; which is now cross-posted to comp.lang.scheme, and ;;; questions 1-8, 2-3, 2-9 and 2-18 into part 5 which ;;; is now cross-posted to comp.lang.clos. ;;; Added detail to Norvig entry in 1-1. ;;; Updated entries for several Lisp implementations. ;;; 26-MAY-92 mk 1.19 Changed 5-2 on the basis of comments by Jeff Greif. ;;; 29-MAY-92 mk 1.20 Added question [2-17] about lisp sockets. ;;; 16-JUN-92 mk 1.21 Moved the question about object oriented ;;; programming references to part 5 of the FAQ. ;;; Entry on Dylan. Addition to MIT Scheme entry ;;; regarding Schematik. ;;; 22-JUN-92 mk Updated SOAR entry. ;;; 24-JUN-92 mk Fixed MCL entry to note that CLIM is available ;;; from ILA, not via Apple. ;;; 25-JUN-92 mk 1.22 Added question [2-18]. ;;; 17-JUL-92 mk Added entry on PSD (Portable Scheme Debugger). ;;; 20-JUL-92 mk Updated entry on T3.1 ;;; 30-JUL-92 mk Added entry on XIT to question 2-2. ;;; 3-AUG-92 mk Updated PC-Scheme entry (bought by Ibuki). ;;; 6-AUG-92 mk 1.23 Merged in Jeff Dalton's pitfalls list. ;;; 19-AUG-92 mk Added entry on FOCL. Move three questions from ;;; part 2 to part 3, to keep part 2 under 64k. ;;; 26-AUG-92 mk Added some items from Hallvard Tretteberg's ;;; Lisp style guide. ;;; 31-AUG-92 mk 1.24 Updated entries for CMU CL and SIOD. ;;; 8-SEP-92 mk Added entry on VSCM to part 4. Added entry on ;;; Pixie Scheme, Help, and Le-Lisp. ;;; 14-SEP-92 mk Fixed Symbolics entry. Added entry on CLIM-library. ;;; 15-SEP-92 mk Updated MIT C-Scheme entry. ;;; 17-SEP-92 mk Added entry on Lisp-Jobs. Fixed Le-Lisp entry. ;;; Added 3-15. ;;; 23-SEP-92 mk Added entry on COLAB to ftp resources. ;;; Added entry on WCL to Part 4. ;;; 30-SEP-92 mk Added entry on Dr. Dobb's lisp-style C extensions. ;;; Updated entry on Friedman/Wand/Haynes' book. ;;; 9-OCT-92 mk 1.25 Updated Chez Scheme entry. ;;; Added entry on extracting the function name from ;;; the function object, provided by Kerry Koitzsch. ;;; 14-OCT-92 mk 1.26 Split off the ftp resources question from Part 2 ;;; into its own file, now labels Part 6. ;;; Broke up the question into smaller pieces ;;; and reorganized it too. Reorganized Part 4. ;;; 20-OCT-92 mk Added description of Koschmann text, ;;; thanks to L. Mayka. ;;; 27-OCT-92 mk 1.27 Added question 6-6 about formatting code in LaTeX. ;;; 3-NOV-92 mk Added comment on file modularization to 1-2. ;;; Added note on the CLOS code repository to ;;; 6-1. ;;; 5-NOV-92 mk Added info on Lucid benchmark programs in the ;;; goodies/ directory. Also the Lucid ;;; wizards.doc file. ;;; 11-NOV-92 mk Added entry on Karlsruhe CLISP to 4-0. ;;; 13-NOV-92 mk Added entry on ARS MAGNA to part 6, subsection Planning ;;; Testbeds. ;;; 17-NOV-92 mk Added entry on GECO and GAL to 6-3. ;;; 17-NOV-92 mk Updated prices in Allegro CL entry. ;;; 24-NOV-92 mk Added entry on the automatic memoization facility ;;; to part 6. ;;; ------------------------------------------------------------ ;;; *EOF* Xref: bloom-picayune.mit.edu comp.lang.lisp:8750 news.answers:4560 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!spool.mu.edu!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!mkant From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,news.answers Subject: FAQ: Lisp Frequently Asked Questions 2/6 [Monthly posting] Summary: Frequently asked questions about Lisp -- General Questions Message-ID: <lisp-faq-2.text_724237288@cs.cmu.edu> Date: 13 Dec 92 09:01:37 GMT Article-I.D.: cs.lisp-faq-2.text_724237288 Expires: Tue, 26 Jan 1993 09:01:28 GMT Sender: news@cs.cmu.edu (Usenet News System) Reply-To: lisp-faq@think.com Followup-To: poster Organization: School of Computer Science, Carnegie Mellon Lines: 546 Approved: news-answers-request@MIT.Edu Supersedes: <lisp-faq-2.text_721645310@cs.cmu.edu> Nntp-Posting-Host: a.gp.cs.cmu.edu Archive-name: lisp-faq/part2 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; Answers to Frequently Asked Questions about Lisp *************** ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-2.text -- 28371 bytes This post contains Part 2 of the Lisp FAQ. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. Topics Covered (Part 2): [2-1] Is there a GNU-Emacs interface to Lisp? [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp? [2-4] Is Lisp inherently slower than more conventional languages such as C? [2-5] Why does Common Lisp have "#'"? [2-6] How do I call non-Lisp functions from Lisp? [2-7] Can I call Lisp functions from other languages? [2-8] I want to call a function in a package that might not exist at compile time. How do I do this? [2-9] What is CDR-coding? [2-10] What is garbage collection? [2-11] How do I save an executable image of my loaded Lisp system? How do I run a Unix command in my Lisp? How do I get the current directory name from within a Lisp program? [2-12] I'm porting some code from a Symbolics Lisp machine to some other platform, and there are strange characters in the code. What do they mean? [2-13] History: Where did Lisp come from? [2-14] How do I find the argument list of a function? How do I get the function name from a function object? [2-15] How can I have two Lisp processes communicate via unix sockets? Search for [#] to get to question number # quickly. ---------------------------------------------------------------- [2-1] Is there a GNU-Emacs interface to Lisp? ILISP is a powerful GNU-Emacs interface to many dialects of Lisp, including Lucid, Allegro, {A}KCL, IBCL, and CMU. Written by Chris McConnell <ccm+@cs.cmu.edu>. It is available by anonymous ftp from katmandu.mt.cs.cmu.edu [128.2.250.68] in the directory pub/ilisp as the file ilisp.tar.Z. If you start using it, send Chris mail, as he maintains a mailing list of users. Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common Lisp manual. It is available by license from Franz Inc. Contact info@franz.com for more information. There is also a mailing list, lisp-emacs-forum-request@ucbarpa.berkeley.edu. The cl-shell package provides a major mode (cl-shell-mode) for running Common Lisp (CL) as an Emacs subprocess. It provides a general mechanism for communication between CL and Emacs which does not rely on extra processes, and should therefore be easily portable to any version of CL. Features include direct (i.e., not through a temp file) evaluation and in-package compilation of forms from lisp-mode buffers, type-ahead and a history mechanism for the cl-shell buffer, and pop-up help facilities for the CL functions documentation, macroexpand and describe. Extensions for Lucid Common Lisp provide pop-up arglists and source file editing. Other extensions are provided to allow editing source files of CLOS or Flavors methods. Cl-shell is available on the Lucid tape (in the goodies directory) or via anonymous ftp from whitechapel.media.mit.edu (18.85.0.125). Lucid includes some other Emacs-Lisp interfaces in its goodies directory. Harlequin's LispWorks includes an Emacs-Lisp interface. Venue's Medley has an optional EMACS Interface. GNU-Emacs itself is available by anonymous ftp from prep.ai.mit.edu. ---------------------------------------------------------------- [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp? Hopefully, the only reason you need to do this is as part of trying to port some old MacLisp code to Common Lisp. These functions predated the inclusion of strings as a first-class data type in Lisp; symbols were used as strings, and they ere EXPLODEd to allow the individual characters to be manipulated in a list. Probably the best approximations of these are: (defun explode (object) (loop for char across (prin1-to-string object) collect (intern (string char)))) (defun implode (list) (read-from-string (coerce (mapcar #'character list) 'string))) An alternate definition of EXPLODE which uses MAP instead of LOOP is: (defun explode (object) (map 'list #'(lambda (char) (intern (string char))) (prin1-to-string object))) The creation of N conses of garbage to process a string of N characters is a hideously inefficient way of doing the job. Rewrite EXPLODE code with PRIN1-TO-STRING, or better STRING if the arguments are symbols without funny characters. For IMPLODE, try to make its caller use strings and try to make the result usable as a string to avoid having to call INTERN or READ-FROM-STRING. ---------------------------------------------------------------- [2-4] Is Lisp inherently slower than more conventional languages such as C? This is a tough question to answer, as I'm sure you expected. In many cases, it appears to be. Lisp does not require the programmer to specify the data type of variables, so generic arithmetic operators may have to perform type checking at runtime in order to determine how to proceed. However, Lisp code can also be denser (i.e. there is more expressed in a single line) than many other languages: the Lisp expression (+ A B) is more powerful than the C expression A+B (the Lisp version supports bignums, rationals, and complex numbers, while the C version only supports limited-size integers and floating point); therefore, one may claim that it is reasonable that the Lisp version take longer than the C version (but don't expect everyone to accept this rationalization). Solutions to this include hardware support (e.g. processors that support type tags in data, such as SPARC and Symbolics Lisp Machines), declarations, and specialized variants of functions (e.g. in MacLisp, + accepts and returns only fixnums, +$ accepts and returns only flonums, and PLUS is generic). At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's PDP-10 Fortran compiler. When appropriate declarations were supplied in the Lisp code, the performance of compiled Lisp arithmetic rivaled that of the Fortran code. It would hardly be fair to compare Lisp without declarations to Fortran, since the Fortran compiler would have more information upon which it could base its optimizations. Since Lisp is a good language for rapid prototyping, it is easy for a mediocre programmer (or even a good programmer, who isn't being careful) to generate a large amount of inefficient Lisp code. A good example is the use of APPEND to link successive lists together, instead of keeping a pointer to the tail of the list. Often a programmer can obtain significant speed increases by using a time/space profiler to identify the functions which waste time (often small functions which are called frequently) and rewriting those functions. ---------------------------------------------------------------- [2-5] Why does Common Lisp have "#'"? #' is a macro-character which expands #'FOO to (FUNCTION FOO). Symbols in Lisp have two bindings, one for values and one for functions, allowing them to represent both variables and functions, depending on context. #'FOO accesses FOO's lexical function binding in a context where the value interpretation would normally occur. #' is also used to create lexical closures for lambda expressions. A lexical closure is a function which when invoked executes the body of the lambda-expression in the lexical environment within which the closure was created. See pp. 115-117 of CLtL2 for more details. ---------------------------------------------------------------- [2-6] How do I call non-Lisp functions from Lisp? Most Lisp implementations for systems where Lisp is not the most common language provide a "foreign function" interface. As of now there has been no significant standardization effort in this area. They tend to be similar, but there are enough differences that it would be inappropriate to try to describe them all here. In general, one uses an implementation-dependent macro that defines a Lisp function, but instead of supplying a body for the function, one supplies the name of a function written in another language; the argument list portion of the definition is generally augmented with the data types the foreign function expects and the data type of the foreign function's return value, and the Lisp interface function arranges to do any necessary conversions. There is also generally a function to "load" an object file or library compiled in a foreign language, which dynamically links the functions in the file being loaded into the address space of the Lisp process, and connects the interface functions to the corresponding foreign functions. If you need to do this, see the manual for your language implementation for full details. In particular, be on the lookout for restrictions on the data types that may be passed. You may also need to know details about the linkage conventions that are used on your system; for instance, many C implementations prepend an underscore onto the names of C functions when generating the assembler output (this allows them to use names without initial underscores internally as labels without worrying about conflicts), and the foreign function interface may require you to specify this form explicitly. Franz Allegro Common Lisp's "Foreign Function Call Facility" is described in chapter 10 of the documentation. Calling Lisp Functions from C is treated in section 10.8.2. The foreign function interface in Macintosh Common Lisp is similar. The foreign function interface for KCL is described in chapter 10 of the KCL Report. The foreign function interfaces for Lucid on the Vax and Lucid on the Sun4 are incompatible. Lucid's interface is described in chapter 5 of the Advanced User's Guide. ---------------------------------------------------------------- [2-7] Can I call Lisp functions from other languages? In implementations that provide a foreign function interface as described above, there is also usually a "callback" mechanism. The programmer may associate a foreign language function name with a Lisp function. When a foreign object file or library is loaded into the Lisp address space, it is linked with these callback functions. As with foreign functions, the programmer must supply the argument and result data types so that Lisp may perform conversions at the interface. Note that in such foreign function interfaces Lisp is often left "in control" of things like memory allocation, I/O channels, and startup code (this is a major nuisance for lots of people). ---------------------------------------------------------------- [2-8] I want to call a function in a package that might not exist at compile time. How do I do this? Use (funcall (find-symbol "SYMBOL-NAME" :pkg-name) ...). ---------------------------------------------------------------- [2-9] What is CDR-coding? CDR-coding is a space-saving way to store lists in memory. It is normally only used in Lisp implementations that run on processors that are specialized for Lisp, as it is difficult to implement efficiently in software. In normal list structure, each element of the list is represented as a CONS cell, which is basically two pointers (the CAR and CDR); the CAR points to the element of the list, while the CDR points to the next CONS cell in the list or NIL. CDR-coding takes advantage of the fact that most CDR cells point to another CONS, and further that the entire list is often allocated at once (e.g. by a call to LIST). Instead of using two pointers to implement each CONS cell, the CAR cell contains a pointer and a two-bit "CDR code". The CDR code may contain one of three values: CDR-NORMAL, CDR-NEXT, and CDR-NIL. If the code is CDR-NORMAL, this cell is the first half of an ordinary CONS cell pair, and the next cell in memory contains the CDR pointer as described above. If the CDR code is CDR-NEXT, the next cell in memory contains the next CAR cell; in other words, the CDR pointer is implicitly thisaddress+1, where thisaddress is the memory address of the CAR cell. If the CDR code is CDR-NIL, then this cell is the last element of the list; the CDR pointer is implicitly a reference to the object NIL. When a list is constructed incrementally using CONS, a chain of ordinary pairs is created; however, when a list is constructed in one step using LIST or MAKE-LIST, a block of memory can be allocated for all the CAR cells, and their CDR codes all set to CDR-NEXT (except the last, which is CDR-NIL), and the list will only take half as much storage (because all the CDR pointers are implicit). If this were all there were to it, it would not be difficult to implement in software on ordinary processors; it would add a small amount of overhead to the CDR function, but the reduction in paging might make up for it. The problem arises when a program uses RPLACD on a CONS cell that has a CDR code of CDR-NEXT or CDR-NIL. Normally RPLACD simply stores into the CDR cell of a CONS, but in this case there is no CDR cell -- its contents are implicitly specified by the CDR code, and the word that would normally contain the CDR pointer contains the next CONS cell (in the CDR-NEXT case) to which other data structures may have pointers, or the first word of some other object (in the CDR-NIL case). When CDR-coding is used, the implementation must also provide automatic "forwarding pointers"; an ordinary CONS cell is allocated, the CAR of the original cell is copied into its CAR, the value being RPLACD'ed is stored into its CDR, and the old CAR cell is replaced with a forwarding pointer to the new CONS cell. Whenever CAR or CDR is performed on a CONS, it must check whether the location contains a forwarding pointer. This overhead on both CAR and CDR, coupled with the overhead on CDR to check for CDR codes, is generally enough that using CDR codes on conventional hardware is infeasible. There is some evidence that CDR-coding doesn't really save very much memory, because most lists aren't constructed at once, or RPLACD is done on them enough that they don't stay contiguous. At best this technique can save 50% of the space occupied by CONS cells. However, the savings probably depends to some extent upon the amount of support the implementation provides for creating CDR-coded lists. For instance, many system functions on Symbolics Lisp Machines that operate on lists have a :LOCALIZE option; when :LOCALIZE T is specified, the list is first modified and then copied to a new, CDR-coded block, with all the old cells replaced with forwarding pointers. The next time the garbage collector runs, all the forwarding pointers will be spliced out. Thus, at a cost of a temporary increase in memory usage, overall memory usage is generally reduced because more lists may be CDR-coded. There may also be some benefit in improved paging performance due to increased locality as well (putting a list into CDR-coded form makes all the "cells" contiguous). Nevertheless, modern Lisps tend to use lists much less frequently, with a much heavier reliance upon code, strings, and vectors (structures). ---------------------------------------------------------------- [2-10] What is garbage collection? Garbage Collection (GC) refers to the automatic storage allocation mechanisms present in many Lisps. There are several kinds of storage allocation algorithms, but most fall within two main classes: 1. Stop and Copy. Systems which copy active objects from "old" storage to "new" storage and then recycle the old storage. 2. Mark and Sweep. Systems which link together storage used by discarded objects. Generational scavenging garbage collection (aka emphemeral GC) is a variation in which memory is allocated in layers, with tenured (long-lived) objects in the older layers. Rather than doing a full GC of all of memory every time more room is needed, only the last few layers are GCed during an ephemeral GC, taking much less time. Short-lived objects are quickly recycled, and full GCs are then much less frequent. It is most often used to improve the performance of stop and copy garbage collectors. It is possible to implement ephemeral GC in mark and sweep systems, just much more difficult. Stop and copy garbage collection provides simpler storage allocation, avoids fragmentation of memory (intermixing of free storage with used storage). Copying, however, consumes more of the address space, since up to half the space must be kept available for copying all the active objects. This makes stop and copy GC impractical for systems with a small address space or without virtual memory. Also, copying an object requires that you track down all the pointers to an object and update them to reflect the new address, while in a non-copying system you need only keep one pointer to an object, since its location will not change. It is also more difficult to explicitly return storage to free space in a copying system. Garbage collection is not part of the Common Lisp standard. Most Lisps provide a function ROOM which provides human-readable information about the state of storage usage. In many Lisps, (gc) invokes an ephemeral garbage collection, and (gc t) a full garbage collection. ---------------------------------------------------------------- [2-11] How do I save an executable image of my loaded Lisp system? How do I run a Unix command in my Lisp? How do I get the current directory name from within a Lisp program? There is no standard for dumping a Lisp image. Here are the commands from some lisp implementations: Lucid: DISKSAVE Symbolics: Save World [CP command] CMU CL: SAVE-LISP Franz Allegro: EXCL:DUMPLISP (documented) SAVE-IMAGE (undocumented) Medley: IL:SYSOUT or IL:MAKESYS MCL: SAVE-APPLICATION <pathname> &key :toplevel-function :creator :excise-compiler :size :resources :init-file :clear-clos-caches KCL: (si:save-system "saved_kcl") There is no standard for running a Unix shell command from Lisp, especially since not all Lisps run on top of Unix. Here are the commands from some Lisp implementations: Allegro: EXCL:RUN-SHELL-COMMAND Lucid: RUN-PROGRAM (name &key input output error-output (wait t) arguments (if-input-does-not-exist :error) (if-output-exists :error) (if-error-output-exists :error)) KCL: SYSTEM For example, (system "ls -l"). You can also try RUN-PROCESS and EXCLP, but they don't work with all versions of KCL. There's no standard function for finding the current directory from within a Lisp program, since not all Lisp environments have the concept of a current directory. Here are the commands from some Lisp implementations: Lucid: working-directory (which is also SETFable) pwd and cd also work Allegro: current-directory (use excl:chdir to change it) CMU CL: default-directory Allegro also uses the variable *default-pathname-defaults* to resolve relative pathnames, maintaining it as the current working directory. So evaluating (truename "./") in Allegro (and on certain other systems) will return a pathname for the current directory. Likewise, in some VMS systems evaluating (truename "[]") will return a pathname for the current directory. ---------------------------------------------------------------- [2-12] I'm porting some code from a Symbolics Lisp machine to some other platform, and there are strange characters in the code. What do they mean? The Symbolics Zetalisp character set includes the following characters not present in other Lisps: ^] >= greater than or equal to ^\ <= less than or equal to ^Z != not equal to ^^ == equivalent to ^E not ^G pi ^L +/- plus/minus ^H lambda ^F epsilon ^W <--> left/right arrow ^X <-- left arrow ^Y --> right arrow Other special characters to look out for are the font-change characters, which are represented as a ^F followed by a digit or asterisk. A digit means to push font #N onto the stack; an asterisk means to pop the most recent font from the stack. You can clean up the code by replacing "\^F." with "". ---------------------------------------------------------------- [2-13] History: Where did Lisp come from? John McCarthy developed the basics behind Lisp during the 1956 Dartmouth Summer Research Project on Artificial Intelligence. He intended it as an algebraic LISt Processing (hence the name) language for artificial intelligence work. Early implementations included the IBM 704, the IBM 7090, the DEC PDP-1, the DEC PDP-6 and the DEC PDP-10. The PDP-6 and PDP-10 had 18-bit addresses and 36-bit words, allowing a CONS cell to be stored in one word, with single instructions to extract the CAR and CDR parts. The early PDP machines had a small address space, which limited the size of Lisp programs. Milestones in the development of Lisp: 1956 Dartmouth Summer Research Project on AI. 1960-65 Lisp1.5 is the primary dialect of Lisp. 1964- Development of BBNLisp at BBN. late 60s Lisp1.5 diverges into two main dialects: Interlisp (originally BBNLisp) and MacLisp. early 70s Development of special-purpose computers known as Lisp Machines, designed specificly to run Lisp programs. Xerox D-series Lisp Machines run Interlisp-D. Early MIT Lisp Machines run Lisp Machine Lisp (an extension of MacLisp).